Dev#2
Conversation
|
This pull request sets up GitHub code scanning for this repository. Once the scans have completed and the checks have passed, the analysis results for this pull request branch will appear on this overview. Once you merge this pull request, the 'Security' tab will show more code scanning analysis results (for example, for the default branch). Depending on your configuration and choice of analysis tool, future pull requests will be annotated with code scanning analysis results. For more information about GitHub code scanning, check out the documentation. |
| @@ -1,3 +1,4 @@ | |||
| [ezpz_pluginz] | |||
There was a problem hiding this comment.
lets give user option to use either dedicated ezpz.toml or add [tool.ezpz] to their pyproject.toml
| ) | ||
| from ezpz_pluginz.toml_schema import load_config | ||
|
|
||
| app = typer.Typer(name="ezplugins", pretty_exceptions_show_locals=False, pretty_exceptions_short=True) |
There was a problem hiding this comment.
lets name the cli ezpz less chars to type and easier to remember. also notice that there is a theme of using z instead of s ie ezpz_pluginz vs ezpz_plugins
| @app.command(name="help") | ||
| def show_help(command: str = typer.Argument(None, help="Show help for a specific command")) -> None: | ||
| if command: | ||
| command_help = { |
There was a problem hiding this comment.
lets put the cmd help obj in a json file, or just separate py file.
| logger.info("AVAILABLE COMMANDS:") | ||
| logger.info("") | ||
|
|
||
| commands = [ |
There was a problem hiding this comment.
i thought typer add builtin "help" functionality via docs strings?
There was a problem hiding this comment.
it does have builtin help functionality, I'll adapt to that style
|
|
||
|
|
||
| @app.command(name="update") | ||
| def update_plugin( |
There was a problem hiding this comment.
i think push might be more clear than update .. seems this is for pushing a plugin to the registry?
| logger.info(f" {plugin.description}") | ||
|
|
||
| logger.info("") | ||
|
|
There was a problem hiding this comment.
i feel like we should put all the registry related stuff in a subcmd .. ie ezpz registry ...
| import logging | ||
| from typing import ClassVar, Optional | ||
| from pathlib import Path | ||
|
|
There was a problem hiding this comment.
we should be using structlog?
| self.macro_data.append(metadata) | ||
| except (KeyError, ValueError) as e: | ||
| logging.getLogger(__name__).warning(f"Failed to create plugin metadata: {e}") | ||
| super().visit_Call(node) |
There was a problem hiding this comment.
using super() does not seem correct. the visitor pattern typical handles the recurrsion in the base class from
There was a problem hiding this comment.
I'll look deeper into this
There was a problem hiding this comment.
I removed the super() call and explicitly controlled recursion by returning False when processing ezpz_plugin_collect calls, ensuring child nodes are not traversed redundantly.
| [tool.rye] | ||
| dev-dependencies = ["painlezz-macroz"] | ||
| dev-dependencies = [ | ||
| "painlezz-macroz", |
There was a problem hiding this comment.
macroz is only a dev dep? also lets remove painlezz from the name and just call it macroz
There was a problem hiding this comment.
The noop.py macros (class_macro, func_macro) are used at runtime by plugin developers when they write @ezpz_plugin_collect decorators
The macro system is integral to how ezpz_pluginz works - it's used by end users writing plugins, not just during development
metadata collection happens during build/analysis time, the decorators themselves are runtime components
there might be a split where:
The macro decorators (noop.py) are runtime dependencies
The metadata collection visitors (macro_metadata_collector.py) are dev/build-time dependencies
It's somehow both runtime and build, I can adapt a hybrid config if possible (will look it up)
| from typing import Any | ||
|
|
||
|
|
||
| def register_plugin() -> dict[str, Any]: |
There was a problem hiding this comment.
we should use something with narrower typing than dict[str, Any] for users to register a plugin. most likly a pydantic model so that we can also run validations at the same time via the model
No description provided.